The document RFC 2250 [3] describes how several MPEG2 transport stream and program stream packets are to be carried inside the payload of an RTP packet, and also specifies that a single timestamp is attached to each RTP packet.
The MPEG2 specification [1] describes how timestamps are included inside an MPEG2 stream, how at the destination the different timestamps are used to recover a clock in synchronism with the clock at the source side, and how the different timestamps are used to feed the MPEG decoder and to control when to display the elements of the transmitted stream.
The DVB-IP specification [4] describes a generic architecture for distribution of multimedia services over IP networks. This specification adopts RFC2250 as the mechanism for transporting MPEG2 streams over RTP. This is probably the standard using RFC 2250.
Since several MPEG2 packets are carried inside a single RTP packet, some assumptions are needed if the timing of all MPEG2 packets is to be truly reconstructed at the destination side. Usually it is assumed that the entire MPEG2 stream is a constant bit rate stream, or that it is at least piecewise constant, i.e. that the bitrate changes only at the time where PCR or SCR timestamps are inserted inside the stream. This is not necessarily true, and especially, but not only, when only a partial MPEG2-TS is carried (a stream with ‘holes’), e.g. a stream that initially was a constant bit rate stream but in which a certain (possibly large) number of packets have been deleted.
If a number of MPEG2 packets are carried inside such an RTP packet, the RTP timestamp is created at the time that the RTP packet's construction is finalised, i.e. at the time the last MPEG2 packet arrives at the sender. The generation of the RTP packets from the partial TS is done according to FIG. 3
At the destination side, this means that only this last packet's time is known; the time of all other MPEG2 packets can only be estimated. The reconstructed timing of the packets includes a jitter that is given by the uncertainty of the time when the MPEG2 packet was put inside the RTP buffer. This jitter is equal to the time difference of the transmission of two succeeding RTP packets (i.e. to the difference of their time stamps). The MPEG2 clock recovery now extracts from this ‘jittered’ stream the PCR or SCR timestamps, feeds them to a PLL to reconstruct the MPEG clock. The supplementary jitter introduced by the RTP transmission makes that this PLL needs to be more efficient than in the case of an MPEG stream transmitted directly (without RTP). It also leads to a longer time before the clock is synchronised.